[レポート]「プログラマーの夫に買い物を頼んだら」 というジョークに見るプロジェクトを炎上させないコツとは？

AWS事業本部インテグレーション部のいわほりです。

 

プロジェクトを成功させること、妻から依頼された買い物を無難にこなすこと。私にとっては、どちらも日々の重要なテーマです。

このヒントを得るためにセミナーに参加してまいりましたので、レポートします。

セミナー概要

• タイトル：「プログラマーの夫に買い物を頼んだら」 というジョークに見るプロジェクトを炎上させないコツとは？
• 講師：株式会社リソース・シェアリング　内村寛氏
• イベントの説明は以下のとおりです。

クライアントの要望から要件定義を行い、実装を行うのに なぜ炎上してしまう案件があるのでしょうか？ これは、クライアントと開発ベンダーが共通言語で話す事が できていないからです。 そこで、「プログラマーの夫に買い物を頼んだら」という ジョークをケースとして、どのようにプロジェクトを進めて 行くことで炎上を防げるのか、についてお話します。

アジェンダ

セミナーは、次のように構成されていました。

1. キーワード～『共通言語で話せていない』
2. 炎上の具体例
3. 要件定義において大事なこと
4. 仕様変更対応
5. それでも炎上してしまったら

１．キーワード～『共通言語で話せていない』

プロジェクト炎上の根本原因を一言でいうと『共通言語で話せていない』になります。これを掘り下げていく形で講義が進められました。

２．炎上の具体例

有名な２つの例が紹介されました。

例1：オレゴン大学の実験

各ステークホルダーの思いが一致しないIT業界ではすっかり有名なあの絵です。

例２：プログラマーの夫に買い物を頼んだら…

妻：「牛乳を１つ買ってきてちょうだい。そして、もし卵があったら６つお願い」

夫：（牛乳を６つ買って帰宅する）

妻：「なんで牛乳を６つも買ってきたの！？」

夫：「ん？卵があったから…」

 

例２の要件の正誤は以下のとおりですが、誤った要件定義に基づいてプロジェクトが進むと炎上につながります。

（正）

・牛乳を１つ買ってきて欲しい

・卵が売られていれば、卵も６個買ってきて欲しい

（誤）

・牛乳を１つ買ってきて欲しい

・卵が売られていれば、牛乳を（１つではなく）６つ買ってきて欲しい

３．要件定義において大事なこと

誤った要件定義にならないようにするためには、クライアント(妻)と開発ベンダー(夫)の双方が、会話の内容について相手は自分と異なる解釈をしているかも？と考えてみることがポイントです。

その考えに立ったうえでの対策が３つ紹介されました。

対応策1：必ずドキュメント化する

会話だけで解釈を同一にすることは困難です。文字にすることで、相手との認識の齟齬が見えてきます。

対応策２：要望は詳細に記載する

クライアント(妻)は詳細に伝えることを、開発ベンダー(夫)は詳細に理解することを心掛けるようにします。「買い物」プロジェクトであれば、以下のように記載します。

• （牛乳）牛乳が売られていれば、牛乳を１本買ってくる
• （牛乳）牛乳１本は「１リットルの成分無調整牛乳」とする
• （卵）卵が６個以上売られていれば、卵を６個買ってくる
• （卵）卵が５個以下しか売られていなければ、それらを全て買ってくる
• （卵）卵は「Lサイズの鶏卵」とする

対応策３：スピード感をもって進める

実施期間が長くなると要望も増えます。そして、そうやって増える要望は業務上の目標における「幹」ではなく「枝葉」なことが多いようです。

４．仕様変更対応

要件定義以降にも炎上のリスクは潜んでいます。その一つが仕様変更です。クライアントには、変更によるリスクが見えない／見極められない場合があります。実際、プロジェクトの途中ではいろいろなお話をいただきます。

• 設計時：「社内の別の部署でこんなシステムを開発するので、そのデータを連携したい…」
• 開発時：「こんな画面を追加したい…」
• 検収時：「なんか思ってたのと違う…」

対応策1：やはり、ドキュメント化

やはり、会話だけで解釈を同一にするのは困難です。ドキュメント化により「そんなつもりではなかった…」を削減します。

対応策２：継続的な確認

要件を確認するのは要件定義フェーズの一度だけではありません。基本設計、詳細設計、検収と各フェーズに応じたレベルでの確認を継続し、認識を合わせていきます。これを怠り、齟齬の発覚が遅くなればなるほど、プロジェクトへの影響（リカバリの難易度）も大きくなります。

５．それでも炎上してしまったら

それでも全てのプロジェクトが成功するわけではありません。炎上してしまった時こそ、心掛けるべきことがあります。

対応策１：優先順位を整理

一度に全てを解決することは困難です。そのような時ほど冷静に優先順位付けを行います。

対応策２：そして、ドキュメント化

プロジェクトの基本のキのようです。

受講後の感想

受講して感じたことや再確認できたことを３つ記載します。

感想１：言語によるコミュニケーションの限界

クライアントと開発者が同レベルの業務精通度・ITスキルレベルに達することはないとすると、言語（会話・ドキュメント）による意思疎通には限界があります。したがって、その避けられない隙間を埋めるための策を模索する必要があります。具体的には、「絵・図」や「デモ・mock」の活用が挙げられます。

感想２：真の必要性の評価

クライアントの要望に対して技術的な対応可否や難易度は評価しても、業務における真の必要性の評価は忘れがちです。たとえクライアント業務に精通していなくてもそれを検討し提案してみることによって、クライアントがそれを見直すきっかけになれば良いことだと思います。

感想３：仕様変更への適切な対応

たしかに仕様変更はプロジェクトに大小問わず何らかの影響を及ぼしますので、無いに越したことはありません。しかし、たとえ仕様変更要望が発生したとしても、プロジェクト発足時に定める変更フローを粛々と進めることにより、プロジェクトを炎上させない運営が肝要です。

 

全体を通して興味深く受講できました。企画いただいた関係者の皆さまに感謝いたします。

 

最後まで読んでいただき、ありがとうございました。皆さまのプロジェクトの成功とご家庭の円満に少しでもお役に立てれば幸いです。